kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.19981211-19990422/[e-mail] _Sun Mar 7 11:35:13 1999.msg

Internet Message Format | 1999-04-21 | 4KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA07326
    for <[e-mail]>; Sun, 7 Mar 1999 11:35:12 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id LAA28997
    for [e-mail]; Sun, 7 Mar 1999 11:17:46 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: [e-mail] (Frank da Cruz)
Subject: Re: compilation muse
Date: 7 Mar 1999 16:17:45 GMT
Organization: Columbia University
Message-ID: <7bu8r9$sa2$[e-mail]>
To: [e-mail]

In article <[e-mail]>,
digs <[e-mail]> wrote:
: just a wild shot in the dark,
: gnu readline + kermit
: any thoughts?
:
GNU readline is its whole own world, and so is Kermit's command parser.
Each one has features lacking in the other.  Obviously lacking in Kermit's
is any kind of editing except from the right: no EMACS, VI, VMS, DOS, or
other editing styles for editing within the line, and no remapping of
editing keys.  But readline would not know how to expand Kermit variables or
execute its macros, and probably would not be able to provide keyword or
file lists on "?", at least not without significant effort.  Also, C-Kermit
has parsing primitives not only for keywords and filenames, but also
numbers, dates and times, switches, directories, invisible synonyms,
invisible non-unique special abbreviations, etc.  It allows for comments,
continuation, and block structure.  I'm not sure how much of this readline
could handle.  Its filename parser can handle not only file or directory
lists from a given directory, but also recursive lists.  (Much of this
applies to C-Kermit 7.0.)

So yes, there would be some advantages to substituting readline() for
Kermit's command parsing, but we would also lose features essential to both
interactive use and to scripting.  Of course this leads us to the next
(frequently asked) question: why doesn't Kermit use Tcl or Expect or Python
or Rexx, etc etc, for its scripting language?

Because (a) Kermit predates all of those; (b) C-Kermit's source code is
designed to be portable to any platform, and in fact runs not only on UNIX
(all varieties) but also VMS, AOS/VS, Stratus VOS, OS-9, the Amiga, plus
several others that might not be currently supported but have been at one
time: the Macintosh, the Atari ST, etc.  It does not require ANSI C (I'm not
sure if readline does) nor, in fact, any particular library or system API
underneath except its own.  And (c) readline uses curses (or something like
it) since it sends and reads terminal-specific escape sequences, and curses
is not available universally.  But mainly (d) the amount of effort required
to integrate readline in a way that provides 100% backwards compatibility to
millions of existing scripts on all the platforms where C-Kermit runs or
could run is most likely not worth the benefits.

We are frequently asked to provide hooks to external scripting languages,
and in fact have done so in one case: for Rexx in Kermit 95 on OS/2.  But
each combination of external language and platform presents a unique set
of problems.  Other combinations are on our long, long, long list of
possible future projects.

- Frank